1. Field of the Invention
The invention relates generally to the field of computer networking. More specifically, the invention relates to protocols and conventions for computer inter-networking.
2. Description of the Related Art
From within a corporate "intranet" network or a shared private network, the methods and protocols for local area access to computers, devices and data resources within the network is well defined and somewhat uniform, under the control of the administrators of those networks. When users attempt to gain access to those same devices, computers and resources from outside the network, such access is referred to as "remote access". In the past, the most popular physical topology for remote access is a direct dial into a modem bank, which may be at the corporate site or provided for by an ISP (Internet Service Provider). However, this topology impose a heavy administrative burden and monetary cost especially when remote access is attempted through long distance or international toll calls. Thus, there has been a recent trend to provide remote access through an Internet connection. With Internet remote access, the IP (Internet Protocol) connection can be obtained first using any available method, and thus the intranet does not need to maintain a direct physical access point such as a dial-in modem bank. Once a user is "on the Internet" (has achieved an IP connection), a multitude of different protocols and services (limited by the connectivity features of the intranet) can be used on the user's "client" to gain remote access into the intranet. In order to gain remote access, the client must pass the intermediary step, in most cases, of traversing a firewall. The traversal of the firewall can be achieved by using gateway specific software, SSL (Secure Sockets Layer) mechanisms and so on.
Specific client software must have support and awareness of specific firewall traversal methods, and thus generic client software cannot be utilized to penetrate the intranet. For example, a client application such as Netscape.TM. may not be able to traverse the firewall since it lacks the means with which to express entry parameters to "support" the private intranet's firewall scheme. Thus, users are often limited to using software that specifically understands and communicates with the intranet. This restricts the choice of client software greatly such that only a limited set of client applications out of all the multitude of programs available can be used when accessing that private intranet.
These schemes typically tie the firewall access mechanism to the application, instead of making it transparent by placing it inside the underlying networking support. There is a need for general naming mechanism in order to separate application from firewall traversal mechanisms. Furthermore, the firewall has no standard format to download traversal configuration into the client after authentication.
Thus, there is a need for a generic scheme for allowing client applications to be transparent to the remote access and firewall traversal procedure. The scheme should permit any type of remote access/firewall traversal and security method/protocol to be recognized and operated independent of the client application.